Configuring SBC IP-to-IP Routing Rules

The IP-to-IP Routing table lets you configure up to 615 SBC IP-to-IP routing rules.

Configuration of IP-to-IP routing rules includes two areas:

Match: Defines the characteristics of the incoming SIP dialog message (e.g., IP Group from which the message is received).
Action: Defines the action that is done if the incoming call matches the characteristics of the rule (i.e., routes the call to the specified destination).

The device searches the table from top to bottom for the first rule that matches the characteristics of the incoming call. If it finds a matching rule, it sends the call to the destination configured for that rule. If it doesn't find a matching rule, it rejects the call.

Configure stricter rules higher up in the table than less strict rules to ensure the desired rule is used to route the call. Strict refers to the number of matching characteristics configured for the rule. For example, a rule configured with source host name and source IP Group as matching characteristics is stricter than a rule configured with only source host name. If the rule configured with only source host name appears higher up in the table, the device ("erroneously") uses the rule to route calls matching this source host name (even if they also match the rule appearing lower down in the table configured with the source IP Group as well).

The IP-to-IP Routing table lets you route incoming SIP dialog messages (e.g., INVITE) to any of the following IP destinations:

According to registered user Contact listed in the device's registration database (only for User-type IP Groups).
IP Group - the destination is the address configured for the Proxy Set associated with the IP Group.
IP Group Set - the destination can be based on multiple IP Groups for load balancing, where each call may be sent to a different IP Group within the IP Group Set depending on the IP Group Set's definition.
Routing tag - the device sends the call to an IP Group (or IP Group Set) based on a destination tag (determined by Dial Plans or Call Setup Rules).
IP address in dotted-decimal notation or FQDN. Routing to a host name can be resolved using NAPTR/SRV/A-Record.
Request-URI of incoming SIP dialog-initiating requests.
Any registered user in the registration database. If the Request-URI of the incoming INVITE exists in the database, the call is sent to the corresponding contact address specified in the database.
According to result of an ENUM query.
Hunt Group - used for call survivability of call centers (see Configuring Call Survivability for Call Centers).
According to result of LDAP query (for more information on LDAP-based routing, see Routing Based on LDAP Active Directory Queries).
Third-party routing server or ARM, which determines the destination (next hop) of the call (IP Group). The IP Group represents the next device in the routing path to the final destination. For more information, see Centralized Third-Party Routing Server.
Tel destination (Gateway application). The rule redirects the call to the IP-to-Tel Routing table where the device searches for a matching IP-to-Tel routing rule. This feature can also be done for alternative routing. If an IP-to-IP routing rule fails and it is configured with a "Gateway" routing rule as an alternative route, the device uses the IP-to-Tel Routing table to send the call to the Tel. The device identifies (internally) calls re-directed for alternative Gateway routing, by appending a user-defined string to the prefix destination Request-URI user part (by default, "acgateway-<prefix destination>", for example, acgateway-200). The device removes this prefix before sending it to the Tel side. To configure this prefix string, use the [GWDirectRoutePrefix] parameter.
Back to the sender of the incoming message, where the reply can be a SIP response code or a 3xx redirection response (with an optional Contact field to where the sender must re-send the message).

The following figure summarizes the destination types:

To configure and apply an IP-to-IP Routing rule, the rule must be associated with a Routing Policy. The Routing Policy associates the routing rule with an SRD(s). Therefore, the Routing Policy lets you configure routing rules for calls belonging to specific SRD(s). However, as multiple Routing Policies are relevant only for multi-tenant deployments (if needed), for most deployments, only a single Routing Policy is required. As the device provides a default Routing Policy ("Default_SBCRoutingPolicy"), when only one Routing Policy is required, the device automatically assigns the default Routing Policy to the routing rule. If you are implementing LDAP-based routing (with or without Call Setup Rules) and/or Least Cost Routing (LCR), you need to configure these settings for the Routing Policy (regardless of the number of Routing Policies employed). For more information on Routing Policies, see Configuring SBC Routing Policy Rules.

The IP-to-IP Routing table also provides the following features:

Alternative Routing: In addition to the alternative routing/load balancing provided by the Proxy Set associated with the destination IP Group, the table allows the configuration of alternative routes where if a route fails, the next adjacent (below) rule in the table that is configured to Alt Route Ignore/Consider Inputs are used. The alternative routing rules can be set to enforce the input matching criteria or to ignore any matching criteria. Alternative routing occurs upon one of the following conditions:
A request sent by the device is responded with one of the following:
SIP response code (e.g., 4xx, 5xx, and 6xx) that is also configured for an Alternative Reasons Set (see Configuring SIP Response Codes for Alternative Routing Reasons) assigned to the IP Group ('SBC Alternative Routing Reasons Set' parameter).
SIP 408 Timeout or no response (after timeout).
The DNS resolution includes IP addresses that the device has yet to try (for the current call).

Messages are re-routed with the same SIP Call-ID and CSeq header fields (increased by 1).

If the Proxy Set (see Configuring Proxy Sets) associated with the destination of the call is configured with multiple IP addresses, the device first attempts to route the call to one of these IP addresses, starting with the first listed address. Only when the call cannot be routed to any of the Proxy Set’s IP addresses does the device search the IP-to-IP Routing table for an alternative routing rule for the call.

Load Balancing: You can implement load balancing of calls, belonging to the same source, between a set of destination IP Groups known as an IP Group Set. The IP Group Set can include up to five IP Groups (Server-type and/or Gateway-type only) and the chosen IP Group depends on the configured load-balancing policy (e.g., Round Robin). To configure the feature, you need to first configure an IP Group Set (see Configuring IP Group Sets), and then assign it to a routing rule with 'Destination Type' configured to IP Group Set.
Re-routing SIP Requests: This table enables you to configure "re-routing" rules of requests (e.g., INVITEs) that the device sends upon receipt of SIP 3xx responses or REFER messages. These rules are configured for destinations that do not support receipt of 3xx or REFER and where the device handles the requests locally (instead of forwarding the 3xx or REFER to the destination).
Least Cost Routing (LCR): If the LCR feature is enabled, the device searches the routing table for matching routing rules and then selects the one with the lowest call cost. The call cost of the routing rule is done by assigning it a Cost Group. To configure Cost Groups, see Least Cost Routing. If two routing rules have identical costs, then the rule appearing higher up in the table (i.e., first-matched rule) is used. If a selected route is unavailable, the device uses the next least-cost routing rule. However, even if a matched rule is not assigned a Cost Group, the device can select it as the preferred route over other matched routing rules that are assigned Cost Groups, according to the default LCR settings configured for the assigned Routing Policy (see Configuring SBC Routing Policy Rules).
Call Forking: The IP-to-IP Routing table can be configured to route an incoming IP call to multiple destinations (call forking). The incoming call can be routed to multiple destinations of any type such as an IP Group or IP address. The device forks the call by sending simultaneous INVITE messages to all the specified destinations. It handles the multiple SIP dialogs until one of the calls is answered and then terminates the other SIP dialogs.

Call forking is configured by creating a Forking group. A Forking group consists of a main routing rule ('Alternative Route Options' set to Route Row) whose 'Group Policy' is set to Forking, and one or more associated routing rules ('Alternative Route Options' set to Group Member Ignore Inputs or Group Member Consider Inputs). The group members must be configured in contiguous table rows to the main routing rule. If an incoming call matches the input characteristics of the main routing rule, the device routes the call to its destination and all those of the group members.

An alternative routing rule can also be configured for the Forking group. The alternative route is used if the call fails for the Forking group (i.e., main route and all its group members). The alternative routing rule must be configured in the table row immediately below the last member of the Forking group. The 'Alternative Route Options' of this alternative route must be set to Alt Route Ignore Inputs or Alt Route Consider Inputs. The alternative route can also be configured with its own forking group members, where if the device uses the alternative route, the call is also sent to its group members. In this case, instead of setting the alternative route's 'Group Policy' to None, you must set it to Forking. The group members of the alternative route must be configured in the rows immediately below it.

The LCR feature can also be employed with call forking. The device calculates a maximum call cost for each Forking group and routes the call to the Forking group with the lowest cost. Thus, even if the call can successfully be routed to the main routing rule, a different routing rule can be chosen (even an alternative route, if configured) based on LCR. If routing to one Forking group fails, the device tries to route the call to the Forking group with the next lowest cost (main or alternative route), and so on. The prerequisite for this functionality is that the incoming call must successfully match the input characteristics of the main routing rule.

Tags Representing Source / Destination Numbers: If your deployment includes calls of many different called (source URI user part) and/or calling (destination URI user part) numbers that need to be routed to the same destination, you can employ user-defined tags to represent these numbers. Therefore, instead of configuring many routing rules, you can configure only one routing rule using the tag(s) as the source or destination number matching characteristics, and a destination for the calls. Tags can be obtained using Dial Plans (see Using Dial Plan Tags for Matching Routing Rules) or Call Setup Rules (Configuring Call Setup Rules).
Destination Tags for Determining Destination IP Group: Instead of configuring multiple routing rules, you can configure a single routing rule with a destination tag. The tag can be determined using Dial Plans or Call Setup Rules. The device uses the tag to search the IP Groups table for a destination IP Group that matches the tag ('Tags' parameter). For more information on tag-based routing, see Using Destination Tags for Choosing Routing Destinations.
Fax Rerouting: You can configure the device to reroute incoming calls that it identifies as fax calls to a new IP destination. For more information, see Configuring Rerouting of Calls to Fax Destinations.

Call forking is not applicable to LDAP-based routing.

The following procedure describes how to configure IP-to-IP routing rules through the Web interface. You can also configure it through ini file [IP2IPRouting] or CLI (configure voip > sbc routing ip2ip-routing).

To configure an IP-to-IP routing rule:
1. Open the IP-to-IP Routing table (Setup menu > Signaling & Media tab > SBC folder > Routing > IP-to-IP Routing).
2. Click New; the following dialog box appears:

3. From the 'Routing Policy' drop-down list, select a Routing Policy (configured in Configuring SBC Routing Policies).
4. Configure an IP-to-IP routing rule according to the parameters described in the table below.
5. Click Apply.

IP-to-IP Routing Table Parameter Descriptions

Parameter

Description

'Routing Policy'

sbc-routing-policy-name

[RoutingPolicyName]

Assigns a Routing Policy to the rule. The Routing Policy associates the rule with an SRD(s). The Routing Policy also defines default LCR settings as well as the LDAP servers used if the routing rule is based on LDAP routing (and Call Setup Rules).

If only one Routing Policy is configured in the Routing Policies table, the Routing Policy is automatically assigned. If multiple Routing Policies are configured, no value is assigned.

To configure Routing Policies, see Configuring SBC Routing Policies.

Note: The parameter is mandatory.

General

'Index'

[Index]

Defines an index number for the new table row.

Note: Each row must be configured with a unique index.

'Name'

route-name

[RouteName]

Defines a descriptive name, which is used when associating the row in other tables.

The valid value is a string of up to 40 characters. By default, no value is defined.

Note: The parameter value can't be configured with the character string "any" (upper or lower case).

'Alternative Route Options'

alt-route-options

[AltRouteOptions]

Determines whether this routing rule is the main routing rule or an alternative routing rule (to the rule defined directly above it in the table).

[0] Route Row = (Default) Main routing rule - the device first attempts to route the call to this route if the incoming SIP dialog's input characteristics matches this rule.
[1] Alternative Route Ignore Inputs = If the call cannot be routed to the main route (Route Row), the call is routed to this alternative route regardless of the incoming SIP dialog's input characteristics.
[2] Alternative Route Consider Inputs = If the call cannot be routed to the main route (Route Row), the call is routed to this alternative route only if the incoming SIP dialog matches this routing rule's input characteristics.
[3] Group Member Ignore Inputs = This routing rule is a member of the Forking routing rule. The incoming call is also forked to the destination of this routing rule. The matching input characteristics of the routing rule are ignored.
[4] Group Member Consider Inputs = This routing rule is a member of the Forking routing rule. The incoming call is also forked to the destination of this routing rule only if the incoming call matches this rule's input characteristics.

Note:

The alternative routing entry ([1] or [2]) must be defined in the next consecutive table entry index to the Route Row entry (i.e., directly below it). For example, if Index 4 is configured as a Route Row, Index 5 must be configured as the alternative route.
The Forking Group members must be configured in a table row that is immediately below the main Forking routing rule, or below an alternative routing rule for the main rule, if configured.
For IP-to-IP alternative routing, configure alternative routing based on the receipt of specific SIP SIP responses (see Configuring SIP Response Codes for Alternative Routing Reasons). However, if no response, ICMP, or a SIP 408 response is received, the device attempts to use the alternative route even if you haven't configured any SIP responses for alternative routing.
Multiple alternative route entries can be configured (e.g., Index 1 is the main route - Route Row - and indices 2 through 4 are configured as alternative routes).

Match

'Source IP Group'

src-ip-group-name

[SrcIPGroupName]

Defines the IP Group from where the IP call is received (i.e., the IP Group that sent the SIP dialog). Typically, the IP Group of an incoming SIP dialog is determined (or classified) using the Classification table (see Configuring Classification Rules).

The default is Any (i.e., any IP Group).

Note: The selectable IP Group for the parameter depends on the assigned Routing Policy (in the 'Routing Policy' parameter in this table). For more information, see Configuring SBC Routing Policy Rules.

'Request Type'

request-type

[RequestType]

Defines the SIP dialog request type (SIP Method) of the incoming SIP dialog.

[0] All (default)
[1] INVITE
[2] REGISTER
[3] SUBSCRIBE
[4] INVITE and REGISTER
[5] INVITE and SUBSCRIBE
[6] OPTIONS

Note:

For User-type IP Groups, if you also need to send REGISTER messages received from this IP Group, then it's recommended that the configured destination of the routing rule is a Server-type IP Group and not an IP address (configured by the 'Destination Type' parameter). If you need to send non-REGISTER messages (e.g., INVITE) to a destination that is configured as an IP address, then you need to configure two IP-to-IP Routing rules for this User-type IP Group -- one for routing REGISTER messages and one for routing non-REGISTER messages.
If the device receives a REFER message, it searches again for a matching routing rule in the IP-to-IP Routing table and then forwards the message to the destination configured of the matched rule.

'Source Username Pattern'

src-user-name-pattern

[SrcUsernamePrefix]

Defines the user part of the incoming SIP dialog's source URI (usually the From URI).

You can use special patterns (notations) to denote the user part. For example, if you want to match this rule to user parts whose last four digits (i.e., suffix) are 4 followed by any three digits (e.g., 4008), then configure this parameter to "(4xxx)". To denote calls without a user part in the URI, use the dollar ($) sign. For available patterns, see Dialing Plan Notation for Routing and Manipulation.

The valid value is a string of up to 60 characters. The default is the asterisk (*) symbol (i.e., any user part).

If this rule is not required, leave this field empty.

Note: If you need to route calls of many different source URI user names to the same destination, you can use tags (see 'Source Tags' parameter below) instead of this parameter.

'Source Host'

src-host

[SrcHost]

Defines the host part of the incoming SIP dialog's source URI (usually the From URI).

The default is the asterisk (*) symbol (i.e., any host name). If this rule is not required, leave this field empty.

'Source Tags'

src-tags

[SrcTags]

Defines a source tag(s) for matching this routing rule.

The source tag can be obtained using a Dial Plan (assigned to the source IP Group or SRD) or Call Setup Rules (assigned to the source IP Group or SIP Interface).

The valid value is:

A string of up to 70 characters.
Up to eight tags, where each tag is separated by a semicolon (;).
Up to seven tags containing a name with a value (e.g., Country=Ireland). If you are configuring multiple tags in the name=value format, the names of each tag must be unique (e.g., Country=Ireland;Land=Scotland).
Only one tag containing a value only (e.g., USA).

By default, no value is defined.

The following example configures the maximum number of tags (i.e., seven name=value tags and one value-only tag): Country=Ireland;Country2=Scotland;Country3=RSA;Country4=Canada;Country5=UK;Country6=France;Country7=Germany;USA.

To configure Dial Plans, see Configuring Dial Plans. To configure tags using Call Setup Rules (i.e., using the SrcTags attribute), see Configuring Call Setup Rules.

Note:

The tag is case insensitive.
Instead of using tags and configuring the parameter, you can use the 'Source Username Pattern' parameter to configure a specific URI source user part (or all source users).

'Destination Username Pattern'

dst-user-name-pattern

[DestUsernamePrefix]

Defines the incoming SIP dialog's destination URI (usually the Request URI) user part.

You can use special patterns (notations) to denote the user part. For example, if you want to match this rule to user parts whose last four digits (i.e., suffix) are 4 followed by any three digits (e.g., 4008), then configure this parameter to "(4xxx)". To denote calls without a user part in the URI, use the dollar ($) sign. For available patterns, see Dialing Plan Notation for Routing and Manipulation.

The valid value is a string of up to 60 characters. The default is the asterisk (*) symbol (i.e., any user part). If this rule is not required, leave this field empty.

Note: If you need to route calls of many different destination URI user names to the same destination, you can use tags (see 'Source Tags' parameter below) instead of this parameter.

'Destination Host'

dst-host

[DestHost]

Defines the host part of the incoming SIP dialog’s destination URI (usually the Request-URI).

The default is the asterisk (*) symbol (i.e., any destination host). If this rule is not required, leave this field empty.

'Destination Tags'

dest-tags

[DestTags]

Defines a destination tag(s) for matching this routing rule.

The destination tag can be obtained using a Dial Plan (assigned to the source IP Group or SRD) or Call Setup Rules (assigned to the source IP Group or SIP Interface).

The valid value is:

A string of up to 70 characters.
Up to eight tags, where each tag is separated by a semicolon (;).
Up to seven tags containing a name with a value (e.g., Country=Ireland). If you are configuring multiple tags in the name=value format, the names of each tag must be unique (e.g., Country=Ireland;Land=Scotland).
Only one tag containing a value only (e.g., USA).

By default, no value is defined.

The following example configures the maximum number of tags (i.e., seven name=value tags and one value-only tag): Country=Ireland;Country2=Scotland;Country3=RSA;Country4=Canada;Country5=UK;Country6=France;Country7=Germany;USA.

To configure Dial Plans, see Configuring Dial Plans. To configure tags using Call Setup Rules (i.e., using the DstTags attribute), see Configuring Call Setup Rules.

Note:

The tag is case insensitive.
Instead of using tags and configuring the parameter, you can use the 'Destination Username Pattern' parameter to configure a specific URI destination user (or all destinations users).

'Message Condition'

message-condition-name

[MessageConditionName]

Assigns a SIP Message Condition rule to the IP-to-IP Routing rule.

To configure Message Condition rules, see Configuring Message Condition Rules.

'Call Trigger'

trigger

[Trigger]

Defines the reason (i.e., trigger) for re-routing (i.e., alternative routing) the SIP request.

[0] Any = (Default) This routing rule is used for all scenarios (re-routes and non-re-routes).
[1] 3xx = Re-routes the request if it was triggered as a result of a SIP 3xx response.
[2] REFER = Re-routes the INVITE if it was triggered as a result of a REFER request.
[3] 3xx or REFER = Applies to optional values 3xx and REFER.
[4] Initial only = This routing rule is used for regular requests that the device forwards to the destination. This rule is not used for re-routing of requests triggered by the receipt of REFER or 3xx.
[5] Broken Connection = If the device detects a broken RTP or MSRP connection (no packets received for a user-defined timeout) during the call and the Broken RTP/MSRP Connection feature is enabled (IP Profile parameter 'Broken Connection Mode' configured to Reroute or Reroute with Original SIP Headers), you can use this option as an explicit matching characteristics to route the call to an alternative destination. Therefore, for alternative routing upon broken RTP or MSRP detection, position the routing rule configured with this option above the regular routing rule associated with the call. Such configuration ensures that the device uses this alternative routing rule only when RTP or MSRP broken connection is detected.
[6] Fax Rerouting = Reroutes the INVITE to a fax destination (different IP Group) if it is identified as a fax call. For more information, see Configuring Rerouting of Calls to Fax Destinations.

'ReRoute IP Group'

re-route-ip-group-id

[ReRouteIPGroupName]

Defines the IP Group that initiated (sent) the SIP redirect response (e.g., 3xx) or REFER message. This parameter is typically used for rerouting requests (e.g., INVITEs) when interworking is required for SIP 3xx redirect responses or REFER messages. For more information, see Interworking SIP 3xx Redirect Responses and Interworking SIP REFER Messages, respectively. The parameter functions together with the 'Call Trigger' parameter (in the table).

The default is Any (i.e., any IP Group).

Note: The selectable IP Group for the parameter depends on the assigned Routing Policy (in the 'Routing Policy' parameter in this table). For more information, see Configuring SBC Routing Policy Rules.

Action

'Destination Type'

dst-type

[DestType]

Defines the type of destination to where the device sends the outgoing SIP dialog.

[0] IP Group = (Default) The device sends the SIP dialog to the IP Group as configured in the 'Destination IP Group' parameter. For more information on the actual address, see the 'Destination IP Group' parameter.
[1] Dest Address = The device sends the SIP dialog to the address that is configured by the following parameters: 'Destination Address', 'Destination Port', and 'Destination Transport Type'.
[2] Request URI = The device sends the SIP dialog to the address indicated in the incoming SIP Request-URI. If you have configured the 'Destination Port' and 'Destination Transport Type' parameters, the device overrides the parameters of the incoming Request-URI and these parameters take precedence.
[3] ENUM = The device sends an ENUM query to include the destination address. If you have configured the 'Destination Port' and 'Destination Transport Type' parameters, the device overrides the parameters of the incoming Request-URI and these parameters take precedence.
[4] Hunt Group = This option is used for call center survivability (see Configuring Call Survivability for Call Centers).
[5] Dial Plan = (For Backward Compatibility Only - see Note below) The IP destination is determined by a Dial Plan index of the loaded Dial Plan file. The syntax of the Dial Plan index in the Dial Plan file is as follows: <destination / called prefix number>,0,<IP destination>

Note that the second parameter "0" is ignored. An example of a configured Dial Plan (# 6) in the Dial Plan file is shown below:

[ PLAN6 ]
200,0,10.33.8.52 ; called prefix 200 is routed to destination 10.33.8.52
201,0,10.33.8.52
300,0,itsp.com ; called prefix 300 is routed to destination itsp.com

Once the Dial Plan is defined, you need to assign it (0 to 7) to the routing rule as the destination in the 'Destination Address' parameter, where "0" denotes [PLAN1], "1" denotes [PLAN2], and so on.

[7] LDAP = This option does LDAP-based routing. Make sure that the Routing Policy assigned to the routing rule is configured with the LDAP Server Group for defining the LDAP server(s) to query.
[8] Gateway = The device sends the SBC call to the Tel side (Gateway call) using an IP-to-Tel routing rule in the IP-to-Tel Routing table (see Configuring IP-to-Tel Routing Rules). The IP-to-Tel routing rule must be configured with the same call matching characteristics as this SBC IP-to-IP routing rule. This option is also used for alternative routing of an IP-to-IP route to the PSTN. In such a case, the IP-to-Tel routing rule must also be configured with the same call matching characteristics as this SBC IP-to-IP routing rule.

Note:

If you configure the parameter to Gateway for a rule that is used for alternative routing (i.e., 'Alternative Route Options' parameter is configured to any value other than Route Row), the device uses two DSP session resources. One session resource is for the new Gateway route and one for the initial SBC session used for the incoming leg.
When the device uses this rule that is configured to Gateway and the 'Alternative Route Options' parameter is configured to Route Row, it ignores all other matching rules listed below this rule in the IP-to-IP Routing table.
[9] Routing Server = The device sends a request to a third-party routing server or ARM for an appropriate destination (next hop) for the matching call.
[10] All Users = The device checks if the SIP Request-URI (i.e., destination user) in the incoming INVITE is registered in its' users database. If registered, the device sends the INVITE to the address of the corresponding contact that is specified in the database. If the Request-URI is not registered, the call is rejected.

If the incoming SIP dialog is a REGISTER message, the device acts as a registrar and only responds to the sender of the request (200 OK) without sending the REGISTER message to a destination (i.e., termination of REGISTER messages).

[11] IP Group Set = The device employs load balancing and sends the call to an IP Group in the IP Group Set that you assigned using the 'IP Group Set' parameter (below).
[12] Destination Tag = The device sends the call to an IP Group that is matched by destination tag. For more information on tag-based routing, see Using Destination Tags for Choosing Routing Destinations.

Note: For tag-based routing, you also need to configure the 'Routing Tag Name' parameter (below).

[13] Internal = Instead of sending the incoming SIP dialog to another destination, the device replies to the sender of the dialog with a SIP response code or a redirection response, configured by the 'Internal Action' parameter below.

Note:

Use the Dial Plan option only for backward compatibility purposes; otherwise, use prefix tags as described in Configuring Dial Plans.
If you configure the parameter to Dest Address, Request URI, ENUM, Dial Plan or LDAP, you must specify a destination IP Group using the 'Destination IP Group' parameter, even though these calls are not sent to the specified IP Group (i.e., its associated Proxy Set). This allows you to associate other configuration entities (such as an IP Profile) that are assigned to the IP Group, with the destination of these calls. If you do not specify a destination IP Group, the device uses its own logic in choosing a destination IP Group (and thus its associated configuration entities) for the routing rule.
You can configure up to 20 IP-to-IP Routing rules whose 'Destination Type' is Internal.

'Destination IP Group'

dst-ip-group-name

[DestIPGroupName]

Defines the IP Group to where you want to route the call. The actual destination of the SIP dialog message depends on the IP Group type (as defined in the 'Type' parameter):

Server-type IP Group: The SIP dialog is sent to the IP address configured for the Proxy Set that is associated with the IP Group.
User-type IP Group: The device checks if the SIP dialog is from a registered user, by searching for a match between the Request-URI of the received SIP dialog and an AOR registration record in the device's database. If found, the device sends the SIP dialog to the IP address specified in the database for the registered contact.

By default, no value is defined.

Note:

The parameter is applicable only if the 'Destination Type' parameter is configured to IP Group. However, you also need to specify this parameter if the 'Destination Type' parameter is configured to Dest Address, Request URI, ENUM, Dial Plan or LDAP (even though these calls are not sent to the specified IP Group). For these cases, it allows you to associate other configuration entities (such as an IP Profile) that are assigned to the IP Group, with the destination of these calls.
The selectable IP Group for the parameter depends on the assigned Routing Policy (in the 'Routing Policy' parameter in this table). For more information, see Configuring SBC Routing Policy Rules.

'Destination SIP Interface'

dest-sip-interface-name

[DestSIPInterfaceName]

Defines the destination SIP Interface to where the call is sent.

By default, no value is defined.

To configure SIP Interfaces, see Configuring SIP Interfaces.

Note:

The parameter is applicable only if the 'Destination Type' parameter is configured to any value other than IP Group. If the 'Destination Type' parameter is configured to IP Group, the following SIP Interface is used:
Server-type IP Groups: SIP Interface that is assigned to the Proxy Set associated with the IP Group.
User-type IP Groups: SIP Interface is determined during user registration with the device.
For multi-tenancy, if the assigned Routing Policy is not shared (i.e., the Routing Policy is associated with an Isolated SRD), the SIP Interface must be one that is associated with the Routing Policy or with a shared Routing Policy (i.e., the Routing Policy is associated with one or more Shared SRDs). If the Routing Policy is shared, the SIP Interface can be one that is associated with any SRD or Routing Policy (but it's recommended that it belong to the same SRD/Routing Policy or to shared SRD/Routing Policy to avoid "bleeding").

'Destination Address'

dst-address

[DestAddress]

Defines the destination address to where the call is sent.

The valid value is an IP address in dotted-decimal notation or an FQDN (domain name, e.g., domain.com).

If ENUM-based routing is used (i.e., the 'Destination Type' parameter is set to ENUM) the parameter configures the address of the ENUM service, for example, e164.arpa, e164.customer.net or NRENum.net. The device sends the ENUM query containing the destination phone number to an external DNS server, configured in the IP Interfaces table. The ENUM reply includes a SIP URI (user@host) which is used as the destination Request-URI in this routing table.

The valid value is a string of up to 50 characters (IP address or FQDN). By default, no value is defined.

Note:

The parameter is applicable only if the 'Destination Type' parameter is configured to Dest Address [1] or ENUM [3]; otherwise, the parameter is ignored.
When using domain names, enter the DNS server's IP address or alternatively, define these names in the Internal DNS table (see Configuring the Internal SRV Table).
To terminate SIP OPTIONS messages at the device (i.e., to handle them locally), set the parameter to "internal".

'Destination Port'

dst-port

[DestPort]

Defines the destination port to where the call is sent.

'Destination Transport Type'

dst-transport-type

[DestTransportType]

Defines the transport layer type for sending the call.

[-1] = (Default) Not configured. The transport type is determined by the [SIPTransportType] global parameter.
[0] UDP
[1] TCP
[2] TLS
[3] SCTP

'IP Group Set'

ipgroupset-name

[IPGroupSetName]

Assigns an IP Group Set to the routing rule. The device routes the call to one of the IP Groups in the IP Group Set according to the load-balancing policy configured for the IP Group Set. For more information, see Configuring IP Group Sets.

Note: The parameter is applicable only if you configure the 'Destination Type' parameter to IP Group Set (above).

'Pre Route Call Setup Rules Set ID'

pre-route-call-setup-rules-set-id

[PreRouteCallSetupRulesSetId]

Assigns a Call Setup Rule Set ID to the routing rule. The device runs this Call Setup Rules Set if the incoming call matches the characteristics of this routing rule. The device routes the call to the destination according to the routing rule's configured action, only after it has run the Call Setup rules.

To configure Call Setup rules, see Configuring Call Setup Rules.

Note:

If you have assigned a Call Setup Rules Set using both the 'Pre Route Call Setup Rules Set ID' and 'Call Setup Rules Set ID' parameters, the device first runs the Call Setup Rules Set of the 'Pre Route Call Setup Rules Set ID' parameter.
For tag-based routing during the routing stage (IP-to-IP Routing table):
Assign the Call Setup Rules Set that determines the tag name, using the 'Pre Route Call Setup Rules Set ID' parameter (not 'Call Setup Rules Set ID' parameter). This tag overrides tags of any previously run Call Setup Rules Sets (of SIP Interfaces, source IP Groups, or Dial Plans).
Configure the 'Destination Type' parameter to Destination Tag (see above).
Configure the tag name in the 'Routing Tag Name' parameter (see below).
The device uses the resultant tag name to find a matching destination IP Group (i.e., in 'Tags' parameter) in the IP Groups table.
For alternative routing, you can assign a different Call Setup Rules Set to each alternative routing rule so that they each use a different destination tag and therefore, a different destination IP Group.
For more information on tag-based routing, see Using Destination Tags for Choosing Routing Destinations.

'Call Setup Rules Set ID'

call-setup-rules-set-id

[CallSetupRulesSetId]

Assigns a Call Setup Rule Set ID to the routing rule. The device runs the Call Setup rules of this Set ID if the incoming call matches the characteristics of this routing rule. The device routes the call to the destination according to the routing rule's configured action, only after it has run the Call Setup rules.

To configure Call Setup rules, see Configuring Call Setup Rules.

Note:

If you have assigned a Call Setup Rules Set using both the 'Pre Route Call Setup Rules Set ID' and 'Call Setup Rules Set ID' parameters, the device first runs the Call Setup Rules Set of the 'Pre Route Call Setup Rules Set ID' parameter.
If you want to use Call Setup Rules to determine the destination tag, assign the Call Setup Rule Set using the 'Pre Route Call Setup Rules Set ID' parameter (instead of 'Call Setup Rules Set ID').

'Group Policy'

group-policy

[GroupPolicy]

Defines if the routing rule includes call forking.

[0] None = (Default) Call uses only this route (even if Forking Group members are configured in the rows below it).
[1] Forking = Call uses this route and the routes of Forking Group members, if configured (in the rows below it).

Note: Each Forking Group can contain up to 20 members. In other words, up to 20 routing rules can be configured for the same Forking Group.

'Cost Group'

cost-group

[CostGroup]

Assigns a Cost Group to the routing rule for determining the cost of the call.

By default, no value is defined.

To configure Cost Groups, see Configuring Cost Groups.

Note:

To implement LCR and its Cost Groups, you must enable LCR for the Routing Policy assigned to the routing rule (see Configuring SBC Routing Policy Rules). If LCR is disabled, the device ignores the parameter.
The Routing Policy also determines whether matched routing rules that are not assigned Cost Groups are considered as a higher or lower cost route compared to matching routing rules that are assigned Cost Groups. For example, if the 'Default Call Cost' parameter in the Routing Policy is configured to Lowest Cost, even if the device locates matching routing rules that are assigned Cost Groups, the first-matched routing rule without an assigned Cost Group is considered as the lowest cost route and thus, chosen as the preferred route.

'Routing Tag Name'

routing-tag-name

[RoutingTagName]

Defines the destination tag name, which is used to determine the destination IP Group. The device searches the IP Groups table for an IP Group whose 'Tags' parameter value matches this tag name (and value).

The valid value:

A string of up to 70 characters.
Only one tag can be configured.
Only the tag name (not value, if exists) can be configured. For example, if the tag in the Dial Plan rule is "Country=England", configure the parameter to "Country".
The tag is case insensitive.

The default value is "default", meaning that the device uses the first tag name that is configured without a value. For example, if the Dial Plan rule is configured with tags "Country=England;City=London;Essex", the default tag is "Essex".

An example of configuring this parameter when Call Setup Rules (assigned to the 'Pre Route Call Setup Rules Set ID' parameter above) are used to obtain the tag name: If you configure the parameter to "IPGroupName" (i.e., tag name) and the Call Setup Rule's 'Action Subject' parameter is "DstTags.IPGroupName" which results in the value “Teams” (i.e., tag value), the device searches the IP Groups table for a destination IP Group whose 'Tags' parameter is configured to "ipGroupName=Teams".

For more information on tag-based routing, see Using Destination Tags for Choosing Routing Destinations.

Note:

The parameter is applicable only if the 'Destination Type' parameter is configured to Destination Tag (see above).
If you're using a Call Setup Rule to determine the tag during the device's routing stage, assign the Call Setup Rules Set to the 'Pre Route Call Setup Rules Set ID' parameter (see above).

'Internal Action'

internal-action

[InternalAction]

Defines a SIP response code (e.g., 200 OK) or a redirection response (with an optional Contact field indicating to where the sender must re-send the message) that the device sends to the sender of the incoming SIP dialog (instead of sending the call to another destination). The parameter is applicable only when the 'Destination Type' parameter in this table is configured to Internal (see above).

The valid value syntax (case-insensitive) is:

For SIP response codes:
reply(response='<code>') 

The following example sends a SIP 200:

reply(response='200')
For redirection responses:
redirect(response='<code>',contact='sip:'+….)
redirect(contact='…',response='<code>')
redirect(contact='sip:user@host')

Examples:

The device responds to the dialog with a SIP 300 redirect response that includes a contact value:
redirect(response=’300’,contact=’sip:102@host’)
The device redirects the call from the sender to a SIP Recording Server (SRS):
redirect(response='302',contact='sip:'+header.to.url.user+'@siprecording.com')

You can use the built-in syntax editor to help you configure the field. Click the Editor button located alongside the field to open the Editor, and then simply follow the on-screen instructions.

Note:

The parameter can be used for normal and alternative routing.
The response code for redirect messages can only be 3xx.

'Modified Destination User Name'

modified-dest-user-name

[ModifiedDestUserName]

Defines the user part of the Request-URI in the outgoing SIP dialog message.

The valid value is a string of up to 60 characters. By default, no value is defined.

Note: The parameter is currently used only when the device communicates with VoiceAI Connect.